| Name |
Configure an intuitive name for the IP Profile, to facilitate effective management later. |
| SBC Media Security Mode |
Select either:
|
■
|
Not secured [SBC legs negotiate only SRTP/MSRPS
media lines and RTP/MSRP media lines are removed
from the incoming SDP offer-answer] |
|
■
|
Secured [SBC legs negotiate only RTP/MSRP
media lines and SRTP/MSRPS media lines are removed
from the incoming offer-answer] |
|
■
|
As is (default) [No special handling for RTP/SRTP
and MSRP/MSRPS is done] |
|
■
|
Both [Each offer-answer is extended (if it isn't already)
to two media lines - one RTP/MSRP and the other
SRTP/MSRPS] |
For more information, see the device User's Manual available from AudioCodes.
|
| Remote 3xx Mode |
Select either:
|
■
|
Handle Locally [The device handles SIP 3xx
responses on behalf of the dialog-initiating UA and
retries the request (e.g., INVITE) using one or more
alternative URIs included in the 3xx response. The
device sends the new request to the alternative
destination according to the IP-to-IP Routing table (the
'Call Trigger' field must be set to 3xx).] |
|
■
|
Local Host [The device changes the host part of the
Contact header in the 3xx response before forwarding
the 3xx response to the dialog-initiating UA. If the 'Local
Host Name' parameter of the IP Group of the dialoginitiating
UA is configured with a non-empty value, the
device changes the host part of the Contact header to
this value. If the 'Local Host Name' is empty, the device
changes the host part to the device's IP address (the
same IP address used in the SIP Via and Contact
headers of messages sent to the IP Group).] |
|
■
|
IP Group Name [If the 'SIP Group Name' parameter
of the IP Group of the dialog-initiating UA is configured
with a non-empty value, the device changes the host
part of the Contact header in the 3xx response to this
value, before forwarding the 3xx response to the
dialog-initiating UA.] |
|
■
|
Database URL [The device changes the Contact
header so that the re-route request is sent through the
device. The device changes the URI in the Contact
header of the received SIP 3xx response to its own URI
and adds a special user prefix ("T~&R_”), which is then
sent to the FEU. The FEU then sends a new INVITE to
the device, which the device then sends to the correct
destination.] |
|
■
|
Transparent (default) [The device forwards the
received SIP 3xx response as is, without changing the
Contact header (i.e., transparent handling)] |
For more information, see the device User's Manual available from AudioCodes.
|
| Remote REFER Mode |
Select either:
|
■
|
Handle Locally (default) [Handles the incoming REFER
request itself without forwarding the REFER. The device
generates a new INVITE to the alternative destination
(transfer target) according to the rules in the IP-to-IP Routing table (the 'Call Trigger' parameter must be set
to REFER).] |
|
■
|
Local Host [In the REFER message received from
the transferor, the device replaces the Refer-To header
value (URL) with the IP address of the device or with the
‘Local Host Name’ parameter value configured for the
IP Group (transferee) to where the device forwards the
REFER message. This ensures that the transferee sends
the re-routed INVITE back to the device which then
sends the call to the transfer target.] |
|
■
|
IP Group Name [Changes the host part in the
REFER message to the name configured for the IP
Group (in the IP Groups table).] |
|
■
|
Database URL [SIP Refer-To header value is
changed so that the re-routed INVITE is sent through
the device:
|
|
✔
|
Before forwarding the REFER request, the device
changes the host part to the device's IP address
and adds a special prefix ("T~&R_") to the Contact
user part.
|
|
✔
|
The incoming INVITE is identified as a REFER-resultant
INVITE according to this special prefix.
|
|
✔
|
The device replaces the host part in the Request-
URI with the host from the REFER contact. The special
prefix remains in the user part for regular classification,
manipulation, and routing. The special
prefix can also be used for specific routing rules for
REFER-resultant INVITEs.
|
|
✔
|
The special prefix is removed before the resultant
INVITE is sent to the destination ((transfer target).] |
|
■
|
Keep URI (user@host) [The device forwards the
REFER message without changing the URI (user@host)
in the SIP Refer-To header. If you configure the 'Remote
Replaces Mode' parameter (see below) to any value
other than Keep as is, the devicemay modify the
'replaces' parameter of the Refer-To header to reflect
the call identifiers of the leg. This applies to all types of
call transfers (e.g., blind and attendant transfer).] |
|
■
|
Regular [SIP Refer-To header value is
unchanged and the device forwards the REFER
message as is. However, if you configure the 'Remote
Replaces Mode' parameter (see next) to any value
other than (keep) As is, the device may modify the URI
of the Refer-To header to reflect the call identifiers of
the leg.] |
For more information, see the device User's Manual available from AudioCodes.
|
|
Remote Replaces Mode
|
Select either:
|
■
|
Standard (default) [The SIP UA supports INVITE
messages containing Replaces headers. The device
forwards the INVITE message containing the Replaces
header to the SIP UA. The device may change the value of the Replaces header to reflect the call identifiers of
the leg.] |
|
■
|
Handle Locally [The SIP UA does not support
INVITE messages containing Replaces headers. The
device terminates the received INVITE containing the
Replaces header and establishes a new call between
the SIP UA and the new call party. It then disconnects
the call with the initial call party, by sending it a SIP BYE
request.] |
|
■
|
As is [The SIP UA supports INVITE messages
containing Replaces headers. The device forwards the
Replaces header as is in incoming REFER and outgoing
INVITE messages from/to the SIP UA (i.e., Replaces
header's value is unchanged).] |
For more information, see the device User's Manual available from AudioCodes.
|
|
ICE Mode
|
Enables Interactive Connectivity Establishment (ICE) Lite
for the SIP UA associated with the IP Profile. ICE is a
methodology for NAT traversal, employing the Session
Traversal Utilities for NAT (STUN) and Traversal Using
Relays around NAT (TURN) protocols to provide a peer with
a public IP address and port that can be used to connect to
a remote peer.
For example, (ICE) Lite is required when the device operates
in Microsoft Teams Direct Routing (media bypass)
environments.
Select either:
For more information, see the device User's Manual available from AudioCodes.
|
|
SIP Update Support
|
Select either:
|
■
|
Supported Only After Connect [The UA supports
receipt of UPDATE messages, but only after the call
is connected.] |
|
■
|
Not Supported [The UA doesn't support receipt of UPDATE messages.] |
|
■
|
According Remote Allow [For refreshing the timer
of currently active SIP sessions, the device sends
session refreshes using SIP UPDATE messages only if
the SIP Allow header in the last SIP message received
from the user contains the value "UPDATE". If the Allow
header does not contain the "UPDATE" value (or if the
parameter is not configured to this option), the device
uses INVITE messages for session refreshes.] |
|
■
|
Supported (default) [The UA supports receipt
of UPDATE messages during call setup and after call
establishment.] |
For more information, see the SBC User's Manual available from AudioCodes.
|
|
Remote re-INVITE
|
Defines if the SIP UA associated with this IP Profile supports
receipt of SIP re-INVITE messages.
Select either:
|
■
|
Not Supported [The UA doesn't support receipt of re-INVITE messages. If the device receives a
re-INVITE from another UA that is destined to this UA,
the device "terminates" the re-INVITE and sends a SIP
response to the UA that sent it, which can be a success
or a failure, depending on whether the device can
bridge the media between the UAs.] |
|
■
|
Supported only with SDP [The UA supports receipt of re-INVITE messages, but only if they contain
an SDP body. If the incoming re-INVITE from another
UA doesn't contain SDP, the device creates and adds an
SDP body to the re-INVITE that it forwards to the UA.] |
|
■
|
Supported (default) [The UA supports receipt
of re-INVITE messages with or without SDP.] |
For more information, see the SBC User's Manual available from AudioCodes.
|
|
Remote Delayed Offer Support
|
Defines if the remote UA supports delayed offer (i.e., initial
INVITE requests without an SDP offer).
Select either:
For more information, see the SBC User's Manual available from AudioCodes.
|
|
Remote Representation Mode
|
Select either:
|
■
|
According to Operation Mode (default) [Depends
on the setting of the 'Operation Mode' parameter in
the IP Groups or SRDs table:
|
|
✔
|
B2BUA: Device operates as if the parameter is set
to Replace Contact. |
|
✔
|
Call State-full Proxy: Device operates as if the
parameter is set to Add Routing Headers.] |
|
■
|
Replace Contact [The URI host part in the Contact
header of the received message (from the other side) is
replaced with the device's address or with the value of
the 'SIP Group Name' parameter (configured in the IP Groups table) in the outgoing message sent to the SIP UA.] |
|
■
|
Add Routing Headers [Device adds a Record-Route
header for itself to outgoing messages
(requests\responses) sent to the SIP UA in dialog-setup
transactions. The Contact header remains unchanged.] |
|
■
|
Transparent [Device doesn't change the Contact
header and doesn't add a Record-Route header for
itself. Instead, it relies on its' own inherent mechanism
to remain in the route of future requests in the dialog
(for example, relying on the way the endpoints are set
up or on TLS as the transport type).] |
For more information, see the SBC User's Manual available from AudioCodes.
|
|
Remote Hold Format
|
Defines the format of the SDP in the SIP re-INVITE (or
UPDATE) for call hold that the device sends to the held
party.
Select either:
|
■
|
Hold and Retrieve Not Supported [This option can
be used when the remote side does not support call
hold and retrieve (resume). The device terminates call
hold and call retrieve requests received on the leg
interfacing with the initiator of the call hold/retrieve,
and replies to this initiator with a SIP 200 OK response.
Therefore, the device does not forward call hold and/or
retrieve requests to the remote side.] |
|
■
|
Inactive [Device sends SDP with 'a=inactive'] |
|
■
|
Send Only [Device sends SDP with 'a=sendonly] |
|
■
|
Not Supported [This option can be used when the
remote side does not support call hold. The device
terminates call hold requests received on the leg
interfacing with the initiator of the call hold, and replies
to this initiator with a SIP 200 OK response. However,
call retrieve (resume) requests received from the
initiator are forwarded to the remote side. The device
can play a held tone to the held party if the 'Play Held Tone' parameter is set to Internal.] |
|
■
|
Inactive Zero IP [Device sends SDP with 'a=inactive'
and 'c=0.0.0.0'.] |
|
■
|
Send Only Zero IP [Device sends SDP with
'a=sendonly' and 'c=0.0.0.0'] |
|
■
|
Transparent (default) [Device forwards SDP as is] |
For more information, see the device User's Manual available from AudioCodes.
|
